Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC3026: "busy" presence state #3026

Open
wants to merge 7 commits into
base: old_master
Choose a base branch
from

Conversation

babolivier
Copy link
Contributor

@babolivier babolivier commented Feb 23, 2021

Rendered

Synapse implementation: matrix-org/synapse#9644
Element Android implementation: element-hq/element-android#6047
Element Web implementation: matrix-org/matrix-react-sdk#8043

FCP proposal: #3026 (comment)

@babolivier babolivier changed the title MSCXXXX: "busy" presence state MSC3026: "busy" presence state Feb 23, 2021
@anoadragon453 anoadragon453 added kind:feature MSC for not-core and not-maintenance stuff proposal A matrix spec change proposal proposal-in-review labels Feb 23, 2021
@ShadowJonathan

This comment has been minimized.

@babolivier

This comment has been minimized.

Copy link
Member

@dbkr dbkr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Presence right now is fairly basic, and it's also unclear how it might interact with user profiles, ie. if some of it might move there (the status_msg in particular?) but it certainly seems like the semantics of 'busy' being something that will be auto-set by clients lend it to being in the presence enum. However presence ends up evolving, I think it having a busy state included allows for clients to set it automatically and server to derive a sensible value from the various automatic updates from clients.

Copy link
Contributor

@ShadowJonathan ShadowJonathan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the proposal as-is (on commit 69c273c) will break the presence system as it works today, I think we need a more expansive presence MSC that can incorporate "extra" presence (such as busy proposed here), instead of the "cumulative" presence we have today (that this proposal will not fit into, for multiple reasons).

Edit: This review is now outdated

Copy link
Contributor

@ShadowJonathan ShadowJonathan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per discussion in #matrix-spec, I've realised that this spec does indeed try to do (what i called) "cumulative" presence, with 2 important points i think should be clarified in this document;

  1. the busy presence is more exclusively seen as a "active temporary" state, i.e. it is not seen as analogous to the generic "do not disturb" status we see in many apps today, but it is meant as a marker to presence-receiving users that the user is currently busy in specifically-engaging activities such as calls. Important note then; this presence should immidiately be dropped when the user is seen as not actively engaging (not in a call) or not present (then unavailable/"idle" should be broadcasted.

  2. With the previous, the busy state is seen as "above" any online state, making it so that only one client has to broadcast it to have it be the defacto "user presence" then, this is similar to online with unavailable, and unavailable with offline.

I think clarifying these two things explicitly in this document (if they arent already) would make this MSC non-conflicting with how matrix works today, assuming that clients honor point 1.

Copy link
Member

@turt2live turt2live left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally we'd rework the entire presence system so that things like unavailable make sense, but this is probably the best we can do for now.

Copy link
Member

@anoadragon453 anoadragon453 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally looks fine, just a couple of points really.

proposals/3026-presence-busy.md Outdated Show resolved Hide resolved
proposals/3026-presence-busy.md Outdated Show resolved Hide resolved
Copy link
Member

@anoadragon453 anoadragon453 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This lgtm on the whole!

proposals/3026-presence-busy.md Show resolved Hide resolved
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Apr 28, 2021
Synapse 1.32.2 (2021-04-22)
===========================

This release includes a fix for a regression introduced in 1.32.0.

Bugfixes
--------

- Fix a regression in Synapse 1.32.0 and 1.32.1 which caused `LoggingContext` errors in plugins. ([\#9857](matrix-org/synapse#9857))


Synapse 1.32.1 (2021-04-21)
===========================

This release fixes [a regression](matrix-org/synapse#9853)
in Synapse 1.32.0 that caused connected Prometheus instances to become unstable.

However, as this release is still subject to the `LoggingContext` change in 1.32.0,
it is recommended to remain on or downgrade to 1.31.0.

Bugfixes
--------

- Fix a regression in Synapse 1.32.0 which caused Synapse to report large numbers of Prometheus time series, potentially overwhelming Prometheus instances. ([\#9854](matrix-org/synapse#9854))


Synapse 1.32.0 (2021-04-20)
===========================

**Note:** This release introduces [a regression](matrix-org/synapse#9853)
that can overwhelm connected Prometheus instances. This issue was not present in
1.32.0rc1. If affected, it is recommended to downgrade to 1.31.0 in the meantime, and
follow [these instructions](matrix-org/synapse#9854 (comment))
to clean up any excess writeahead logs.

**Note:** This release also mistakenly included a change that may affected Synapse
modules that import `synapse.logging.context.LoggingContext`, such as
[synapse-s3-storage-provider](https://github.com/matrix-org/synapse-s3-storage-provider).
This will be fixed in a later Synapse version.

**Note:** This release requires Python 3.6+ and Postgres 9.6+ or SQLite 3.22+.

This release removes the deprecated `GET /_synapse/admin/v1/users/<user_id>` admin API. Please use the [v2 API](https://github.com/matrix-org/synapse/blob/develop/docs/admin_api/user_admin_api.rst#query-user-account) instead, which has improved capabilities.

This release requires Application Services to use type `m.login.application_service` when registering users via the `/_matrix/client/r0/register` endpoint to comply with the spec. Please ensure your Application Services are up to date.

If you are using the `packages.matrix.org` Debian repository for Synapse packages,
note that we have recently updated the expiry date on the gpg signing key. If you see an
error similar to `The following signatures were invalid: EXPKEYSIG F473DD4473365DE1`, you
will need to get a fresh copy of the keys. You can do so with:

```sh
sudo wget -O /usr/share/keyrings/matrix-org-archive-keyring.gpg https://packages.matrix.org/debian/matrix-org-archive-keyring.gpg
```

Bugfixes
--------

- Fix the log lines of nested logging contexts. Broke in 1.32.0rc1. ([\#9829](matrix-org/synapse#9829))


Synapse 1.32.0rc1 (2021-04-13)
==============================

Features
--------

- Add a Synapse module for routing presence updates between users. ([\#9491](matrix-org/synapse#9491))
- Add an admin API to manage ratelimit for a specific user. ([\#9648](matrix-org/synapse#9648))
- Include request information in structured logging output. ([\#9654](matrix-org/synapse#9654))
- Add `order_by` to the admin API `GET /_synapse/admin/v2/users`. Contributed by @dklimpel. ([\#9691](matrix-org/synapse#9691))
- Replace the `room_invite_state_types` configuration setting with `room_prejoin_state`. ([\#9700](matrix-org/synapse#9700))
- Add experimental support for [MSC3083](matrix-org/matrix-spec-proposals#3083): restricting room access via group membership. ([\#9717](matrix-org/synapse#9717), [\#9735](matrix-org/synapse#9735))
- Update experimental support for Spaces: include `m.room.create` in the room state sent with room-invites. ([\#9710](matrix-org/synapse#9710))
- Synapse now requires Python 3.6 or later. It also requires Postgres 9.6 or later or SQLite 3.22 or later. ([\#9766](matrix-org/synapse#9766))


Bugfixes
--------

- Prevent `synapse_forward_extremities` and `synapse_excess_extremity_events` Prometheus metrics from initially reporting zero-values after startup. ([\#8926](matrix-org/synapse#8926))
- Fix recently added ratelimits to correctly honour the application service `rate_limited` flag. ([\#9711](matrix-org/synapse#9711))
- Fix longstanding bug which caused `duplicate key value violates unique constraint "remote_media_cache_thumbnails_media_origin_media_id_thumbna_key"` errors. ([\#9725](matrix-org/synapse#9725))
- Fix bug where sharded federation senders could get stuck repeatedly querying the DB in a loop, using lots of CPU. ([\#9770](matrix-org/synapse#9770))
- Fix duplicate logging of exceptions thrown during federation transaction processing. ([\#9780](matrix-org/synapse#9780))


Updates to the Docker image
---------------------------

- Move opencontainers labels to the final Docker image such that users can inspect them. ([\#9765](matrix-org/synapse#9765))


Improved Documentation
----------------------

- Make the `allowed_local_3pids` regex example in the sample config stricter. ([\#9719](matrix-org/synapse#9719))


Deprecations and Removals
-------------------------

- Remove old admin API `GET /_synapse/admin/v1/users/<user_id>`. ([\#9401](matrix-org/synapse#9401))
- Make `/_matrix/client/r0/register` expect a type of `m.login.application_service` when an Application Service registers a user, to align with [the relevant spec](https://spec.matrix.org/unstable/application-service-api/#server-admin-style-permissions). ([\#9548](matrix-org/synapse#9548))


Internal Changes
----------------

- Replace deprecated `imp` module with successor `importlib`. Contributed by Cristina Muñoz. ([\#9718](matrix-org/synapse#9718))
- Experiment with GitHub Actions for CI. ([\#9661](matrix-org/synapse#9661))
- Introduce flake8-bugbear to the test suite and fix some of its lint violations. ([\#9682](matrix-org/synapse#9682))
- Update `scripts-dev/complement.sh` to use a local checkout of Complement, allow running a subset of tests and have it use Synapse's Complement test blacklist. ([\#9685](matrix-org/synapse#9685))
- Improve Jaeger tracing for `to_device` messages. ([\#9686](matrix-org/synapse#9686))
- Add release helper script for automating part of the Synapse release process. ([\#9713](matrix-org/synapse#9713))
- Add type hints to expiring cache. ([\#9730](matrix-org/synapse#9730))
- Convert various testcases to `HomeserverTestCase`. ([\#9736](matrix-org/synapse#9736))
- Start linting mypy with `no_implicit_optional`. ([\#9742](matrix-org/synapse#9742))
- Add missing type hints to federation handler and server. ([\#9743](matrix-org/synapse#9743))
- Check that a `ConfigError` is raised, rather than simply `Exception`, when appropriate in homeserver config file generation tests. ([\#9753](matrix-org/synapse#9753))
- Fix incompatibility with `tox` 2.5. ([\#9769](matrix-org/synapse#9769))
- Enable Complement tests for [MSC2946](matrix-org/matrix-spec-proposals#2946): Spaces Summary API. ([\#9771](matrix-org/synapse#9771))
- Use mock from the standard library instead of a separate package. ([\#9772](matrix-org/synapse#9772))
- Update Black configuration to target Python 3.6. ([\#9781](matrix-org/synapse#9781))
- Add option to skip unit tests when building Debian packages. ([\#9793](matrix-org/synapse#9793))


Synapse 1.31.0 (2021-04-06)
===========================

**Note:** As announced in v1.25.0, and in line with the deprecation policy for platform dependencies, this is the last release to support Python 3.5 and PostgreSQL 9.5. Future versions of Synapse will require Python 3.6+ and PostgreSQL 9.6+, as per our [deprecation policy](docs/deprecation_policy.md).

This is also the last release that the Synapse team will be publishing packages for Debian Stretch and Ubuntu Xenial.


Improved Documentation
----------------------

- Add a document describing the deprecation policy for platform dependencies. ([\#9723](matrix-org/synapse#9723))


Internal Changes
----------------

- Revert using `dmypy run` in lint script. ([\#9720](matrix-org/synapse#9720))
- Pin flake8-bugbear's version. ([\#9734](matrix-org/synapse#9734))


Synapse 1.31.0rc1 (2021-03-30)
==============================

Features
--------

- Add support to OpenID Connect login for requiring attributes on the `userinfo` response. Contributed by Hubbe King. ([\#9609](matrix-org/synapse#9609))
- Add initial experimental support for a "space summary" API. ([\#9643](matrix-org/synapse#9643), [\#9652](matrix-org/synapse#9652), [\#9653](matrix-org/synapse#9653))
- Add support for the busy presence state as described in [MSC3026](matrix-org/matrix-spec-proposals#3026). ([\#9644](matrix-org/synapse#9644))
- Add support for credentials for proxy authentication in the `HTTPS_PROXY` environment variable. ([\#9657](matrix-org/synapse#9657))


Bugfixes
--------

- Fix a longstanding bug that could cause issues when editing a reply to a message. ([\#9585](matrix-org/synapse#9585))
- Fix the `/capabilities` endpoint to return `m.change_password` as disabled if the local password database is not used for authentication. Contributed by @dklimpel. ([\#9588](matrix-org/synapse#9588))
- Check if local passwords are enabled before setting them for the user. ([\#9636](matrix-org/synapse#9636))
- Fix a bug where federation sending can stall due to `concurrent access` database exceptions when it falls behind. ([\#9639](matrix-org/synapse#9639))
- Fix a bug introduced in Synapse 1.30.1 which meant the suggested `pip` incantation to install an updated `cryptography` was incorrect. ([\#9699](matrix-org/synapse#9699))


Updates to the Docker image
---------------------------

- Speed up Docker builds and make it nicer to test against Complement while developing (install all dependencies before copying the project). ([\#9610](matrix-org/synapse#9610))
- Include [opencontainers labels](https://github.com/opencontainers/image-spec/blob/master/annotations.md#pre-defined-annotation-keys) in the Docker image. ([\#9612](matrix-org/synapse#9612))


Improved Documentation
----------------------

- Clarify that `register_new_matrix_user` is present also when installed via non-pip package. ([\#9074](matrix-org/synapse#9074))
- Update source install documentation to mention platform prerequisites before the source install steps. ([\#9667](matrix-org/synapse#9667))
- Improve worker documentation for fallback/web auth endpoints. ([\#9679](matrix-org/synapse#9679))
- Update the sample configuration for OIDC authentication. ([\#9695](matrix-org/synapse#9695))


Internal Changes
----------------

- Preparatory steps for removing redundant `outlier` data from `event_json.internal_metadata` column. ([\#9411](matrix-org/synapse#9411))
- Add type hints to the caching module. ([\#9442](matrix-org/synapse#9442))
- Introduce flake8-bugbear to the test suite and fix some of its lint violations. ([\#9499](matrix-org/synapse#9499), [\#9659](matrix-org/synapse#9659))
- Add additional type hints to the Homeserver object. ([\#9631](matrix-org/synapse#9631), [\#9638](matrix-org/synapse#9638), [\#9675](matrix-org/synapse#9675), [\#9681](matrix-org/synapse#9681))
- Only save remote cross-signing and device keys if they're different from the current ones. ([\#9634](matrix-org/synapse#9634))
- Rename storage function to fix spelling and not conflict with another function's name. ([\#9637](matrix-org/synapse#9637))
- Improve performance of federation catch up by sending the latest events in the room to the remote, rather than just the last event sent by the local server. ([\#9640](matrix-org/synapse#9640), [\#9664](matrix-org/synapse#9664))
- In the `federation_client` commandline client, stop automatically adding the URL prefix, so that servlets on other prefixes can be tested. ([\#9645](matrix-org/synapse#9645))
- In the `federation_client` commandline client, handle inline `signing_key`s in `homeserver.yaml`. ([\#9647](matrix-org/synapse#9647))
- Fixed some antipattern issues to improve code quality. ([\#9649](matrix-org/synapse#9649))
- Add a storage method for pulling all current user presence state from the database. ([\#9650](matrix-org/synapse#9650))
- Import `HomeServer` from the proper module. ([\#9665](matrix-org/synapse#9665))
- Increase default join ratelimiting burst rate. ([\#9674](matrix-org/synapse#9674))
- Add type hints to third party event rules and visibility modules. ([\#9676](matrix-org/synapse#9676))
- Bump mypy-zope to 0.2.13 to fix "Cannot determine consistent method resolution order (MRO)" errors when running mypy a second time. ([\#9678](matrix-org/synapse#9678))
- Use interpreter from `$PATH` via `/usr/bin/env` instead of absolute paths in various scripts. ([\#9689](matrix-org/synapse#9689))
- Make it possible to use `dmypy`. ([\#9692](matrix-org/synapse#9692))
- Suppress "CryptographyDeprecationWarning: int_from_bytes is deprecated". ([\#9698](matrix-org/synapse#9698))
- Use `dmypy run` in lint script for improved performance in type-checking while developing. ([\#9701](matrix-org/synapse#9701))
- Fix undetected mypy error when using Python 3.6. ([\#9703](matrix-org/synapse#9703))
- Fix type-checking CI on develop. ([\#9709](matrix-org/synapse#9709))


Synapse 1.30.1 (2021-03-26)
===========================

This release is identical to Synapse 1.30.0, with the exception of explicitly
setting a minimum version of Python's Cryptography library to ensure that users
of Synapse are protected from the recent [OpenSSL security advisories](https://mta.openssl.org/pipermail/openssl-announce/2021-March/000198.html),
especially CVE-2021-3449.

Note that Cryptography defaults to bundling its own statically linked copy of
OpenSSL, which means that you may not be protected by your operating system's
security updates.

It's also worth noting that Cryptography no longer supports Python 3.5, so
admins deploying to older environments may not be protected against this or
future vulnerabilities. Synapse will be dropping support for Python 3.5 at the
end of March.


Updates to the Docker image
---------------------------

- Ensure that the docker container has up to date versions of openssl. ([\#9697](matrix-org/synapse#9697))


Internal Changes
----------------

- Enforce that `cryptography` dependency is up to date to ensure it has the most recent openssl patches. ([\#9697](matrix-org/synapse#9697))


Synapse 1.30.0 (2021-03-22)
===========================

Note that this release deprecates the ability for appservices to
call `POST /_matrix/client/r0/register`  without the body parameter `type`. Appservice
developers should use a `type` value of `m.login.application_service` as
per [the spec](https://matrix.org/docs/spec/application_service/r0.1.2#server-admin-style-permissions).
In future releases, calling this endpoint with an access token - but without a `m.login.application_service`
type - will fail.


No significant changes.


Synapse 1.30.0rc1 (2021-03-16)
==============================

Features
--------

- Add prometheus metrics for number of users successfully registering and logging in. ([\#9510](matrix-org/synapse#9510), [\#9511](matrix-org/synapse#9511), [\#9573](matrix-org/synapse#9573))
- Add `synapse_federation_last_sent_pdu_time` and `synapse_federation_last_received_pdu_time` prometheus metrics, which monitor federation delays by reporting the timestamps of messages sent and received to a set of remote servers. ([\#9540](matrix-org/synapse#9540))
- Add support for generating JSON Web Tokens dynamically for use as OIDC client secrets. ([\#9549](matrix-org/synapse#9549))
- Optimise handling of incomplete room history for incoming federation. ([\#9601](matrix-org/synapse#9601))
- Finalise support for allowing clients to pick an SSO Identity Provider ([MSC2858](matrix-org/matrix-spec-proposals#2858)). ([\#9617](matrix-org/synapse#9617))
- Tell spam checker modules about the SSO IdP a user registered through if one was used. ([\#9626](matrix-org/synapse#9626))


Bugfixes
--------

- Fix long-standing bug when generating thumbnails for some images with transparency: `TypeError: cannot unpack non-iterable int object`. ([\#9473](matrix-org/synapse#9473))
- Purge chain cover indexes for events that were purged prior to Synapse v1.29.0. ([\#9542](matrix-org/synapse#9542), [\#9583](matrix-org/synapse#9583))
- Fix bug where federation requests were not correctly retried on 5xx responses. ([\#9567](matrix-org/synapse#9567))
- Fix re-activating an account via the admin API when local passwords are disabled. ([\#9587](matrix-org/synapse#9587))
- Fix a bug introduced in Synapse 1.20 which caused incoming federation transactions to stack up, causing slow recovery from outages. ([\#9597](matrix-org/synapse#9597))
- Fix a bug introduced in v1.28.0 where the OpenID Connect callback endpoint could error with a `MacaroonInitException`. ([\#9620](matrix-org/synapse#9620))
- Fix Internal Server Error on `GET /_synapse/client/saml2/authn_response` request. ([\#9623](matrix-org/synapse#9623))


Updates to the Docker image
---------------------------

- Make use of an improved malloc implementation (`jemalloc`) in the docker image. ([\#8553](matrix-org/synapse#8553))


Improved Documentation
----------------------

- Add relayd entry to reverse proxy example configurations. ([\#9508](matrix-org/synapse#9508))
- Improve the SAML2 upgrade notes for 1.27.0. ([\#9550](matrix-org/synapse#9550))
- Link to the "List user's media" admin API from the media admin API docs. ([\#9571](matrix-org/synapse#9571))
- Clarify the spam checker modules documentation example to mention that `parse_config` is a required method. ([\#9580](matrix-org/synapse#9580))
- Clarify the sample configuration for `stats` settings. ([\#9604](matrix-org/synapse#9604))


Deprecations and Removals
-------------------------

- The `synapse_federation_last_sent_pdu_age` and `synapse_federation_last_received_pdu_age` prometheus metrics have been removed. They are replaced by `synapse_federation_last_sent_pdu_time` and `synapse_federation_last_received_pdu_time`. ([\#9540](matrix-org/synapse#9540))
- Registering an Application Service user without using the `m.login.application_service` login type will be unsupported in an upcoming Synapse release. ([\#9559](matrix-org/synapse#9559))


Internal Changes
----------------

- Add tests to ResponseCache. ([\#9458](matrix-org/synapse#9458))
- Add type hints to purge room and server notice admin API. ([\#9520](matrix-org/synapse#9520))
- Add extra logging to ObservableDeferred when callbacks throw exceptions. ([\#9523](matrix-org/synapse#9523))
- Fix incorrect type hints. ([\#9528](matrix-org/synapse#9528), [\#9543](matrix-org/synapse#9543), [\#9591](matrix-org/synapse#9591), [\#9608](matrix-org/synapse#9608), [\#9618](matrix-org/synapse#9618))
- Add an additional test for purging a room. ([\#9541](matrix-org/synapse#9541))
- Add a `.git-blame-ignore-revs` file with the hashes of auto-formatting. ([\#9560](matrix-org/synapse#9560))
- Increase the threshold before which outbound federation to a server goes into "catch up" mode, which is expensive for the remote server to handle. ([\#9561](matrix-org/synapse#9561))
- Fix spurious errors reported by the `config-lint.sh` script. ([\#9562](matrix-org/synapse#9562))
- Fix type hints and tests for BlacklistingAgentWrapper and BlacklistingReactorWrapper. ([\#9563](matrix-org/synapse#9563))
- Do not have mypy ignore type hints from unpaddedbase64. ([\#9568](matrix-org/synapse#9568))
- Improve efficiency of calculating the auth chain in large rooms. ([\#9576](matrix-org/synapse#9576))
- Convert `synapse.types.Requester` to an `attrs` class. ([\#9586](matrix-org/synapse#9586))
- Add logging for redis connection setup. ([\#9590](matrix-org/synapse#9590))
- Improve logging when processing incoming transactions. ([\#9596](matrix-org/synapse#9596))
- Remove unused `stats.retention` setting, and emit a warning if stats are disabled. ([\#9604](matrix-org/synapse#9604))
- Prevent attempting to bundle aggregations for state events in /context APIs. ([\#9619](matrix-org/synapse#9619))
@turt2live turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Jun 8, 2021
@chagai95
Copy link

chagai95 commented Jul 8, 2022

We are testing this and it's working fine for us on productive systems, when will it be "merged"?

@anoadragon453
Copy link
Member

@turt2live was the needs-implementation label added due to a lack of an open-source client implementation?

@turt2live turt2live added this to Needs idea feedback / initial review in Spec Core Team Backlog via automation Jul 12, 2022
@turt2live turt2live added push client-server Client-Server API labels Jul 12, 2022
@turt2live turt2live moved this from Needs idea feedback / initial review to Proposed for FCP readiness in Spec Core Team Backlog Jul 12, 2022
Copy link
Member

@anoadragon453 anoadragon453 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This still lgtm.

@mscbot fcp merge

@anoadragon453
Copy link
Member

@mscbot fcp merge

@mscbot
Copy link
Collaborator

mscbot commented Jul 19, 2022

This FCP proposal has been cancelled by #3026 (comment).

Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people:

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

@mscbot mscbot added disposition-merge proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. labels Jul 19, 2022
@turt2live turt2live moved this from Proposed for FCP readiness to Ready for FCP ticks in Spec Core Team Backlog Jul 19, 2022

## Proposal

A new presence state is added, `busy`, which describes a state where the user is
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I don't have an objection to adding busy in particular, this raises the larger question of what presence states we should have. Is it sufficient to just add busy, or do should we be adding more? For example, XMPP defines 6 states (4 states with names, plus a non-specific "online" state when the show element is not present, and a state where the client is offline.) Are we eventually going to want equivalents for XMPP's other states that we're missing? How do we decide where to draw the line?

FWIW, I think that adding a 4th busy state is probably OK. Adding much more than that would be of questionable value.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this was basically my feeling too. How is busy different from unavailable? Should we use status messages instead?

presence state to `unavailable`, which is the closest state to `busy`
semantically.


Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The spec says that the server aggregates presence data across devices, which I assume means that, e.g. if a user has one device that's online and another that's offline, then the user is marked as online. How does busy fit into this? If a user has a device that's online, and one that's busy, what m.presence event should be sent to others? I think that my expectation would be that busy would take precedence over online.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty sure it does in the current implementation. There seems to be one api end point for presence that was overlooked so we disabled it on our forks but when the online state comes through a sync it is ignored by synapse - matrix-org/synapse#12213

Co-authored-by: Hubert Chathi <hubertc@matrix.org>
@babolivier
Copy link
Contributor Author

Thanks for the comments, I'll try to make some time to address them soon.

@turt2live
Copy link
Member

After talking to the author, this isn't the author's current priority. It's hard to make progress on this from the SCT side in this state, so removing from FCP for now - we can always restart FCP when someone is able to pick this up :)

@mscbot fcp cancel

Comment on lines +28 to +30
implementations to not implement a timer that would trigger an update to the
`unavailable` state (like most implementations do when the user is in the
`online` state). This is because there are some valid use cases for the user not
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even though it's obvious, we may also want to explicitly state that homeservers shouldn't update a user's presence state to "online" if activity is detected.

Comment on lines +36 to +42
For backwards compatibility, servers implementing this MSC must expose a flag in
`/_matrix/client/versions` responses, under `unstable_features`, named
`org.matrix.msc3026.busy_presence`, which is set to `true`. Before setting a
user's presence to `busy`, clients must check the presence of this flag and that
it's set to `true`. If it's not, clients should fall back to setting the user's
presence state to `unavailable`, which is the closest state to `busy`
semantically.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sort of backwards compatibility would go in the unstable prefix section - clients (now) can use spec versions to detect support otherwise.

Comment on lines +27 to +34
If a user's presence is set to `busy`, it is strongly recommended for
implementations to not implement a timer that would trigger an update to the
`unavailable` state (like most implementations do when the user is in the
`online` state). This is because there are some valid use cases for the user not
triggering any event in the client but still being online and active, e.g. if
they're on a call, and because such automation while taking the specific
semantics of the `busy` state into account is complex when the user is using
multiple devices.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Synapse (at least) also transitions users to offline in some situations (e.g. if the user stops syncing and enough time has passed). This still seems somewhat valid (e.g. if a device just disappears forever without transition off busy then you at some point want to transition the account to something else).

Comment on lines +22 to +25
It is left to the implementation to decide how to update a user's presence to
the `busy` state (and from this state to another); suggestions would include
allowing the user to set it manually, setting it automatically when the user
joins a call or a Jitsi group call, etc..
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

matrix-org/synapse#12213 asserts that only the /presence API can be used to set busy and that subsequent /sync calls after a user is set to busy should not revert a user to online automatically. I don't think this makes sense and it would be a lot clearer for a client to sync with set_presence=busy if it is still busy. This would give /sync?set_presence=? and /presence the same "power" and not different behavior.

I don't think this MSC could be merged without either documenting the Synapse implementation or a clarification of the MSC.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think this probably does make sense - my basic understanding of it was that the presence API is the 'user level' presence and the sync is the 'device level' presence, so previously the user is busy rather than a device, but this would just be switching to say that a device is busy (which perhaps makes more sense: the user is on a call on a specific device).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client-server Client-Server API kind:feature MSC for not-core and not-maintenance stuff proposal A matrix spec change proposal push
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet